1.26. Что мешает росту
Что мешает росту
Что мешает росту?
В разработке Что мешает росту?
Что мешает разработчику расти?
Нет понимания концепций и методологий
Нет структурного мышления
Копирование без вникания
Слабые коммуникационные навыки
Всё и сразу - неспособность расставлять приоритеты
Отказ от обучения и обратной связи В разработке
Теперь давайте двинемся дальше.
У каждого разработчика, аналитика, тестировщика, может возникнуть ощущение, что он «топчется на месте». Работа может быть однообразной, рутинной, а для повышения требуется освоение нового стека. Знания получить негде, времени нет, и в итоге нет развития. Что же мешает росту?
- Нет понимания концепций и методологий. Разработчик часто умеет писать код, но не понимает, зачем он это делает. Порой не хватает основ и фундамента, так как люди в основном погружаются в то, что требуют. Боятся загружать себя теорией, в стиле «мне бы код писать, а не книжки читать». Обучаются по кнопочкам, по курсам, где дают готовые решения, а не объяснения принципов.
И самое страшное - если отсутствует ментор (наставник), который бы задавал вопросы в стиле «Почему ты выбрал именно этот подход?». Порой именно такой вопрос ставит в ступор разработчика, скопировавшего код с предложенного нейросетью варианта.
В итоге рабочий код невозможно масштабировать, решения поверхностные, ломаются при изменении требований, а об обсуждении архитектурных решений и речи даже не может быть. Появляется зависимость от «старших» - «скажите как делать, я сделаю». В какой-то момент у меня тоже подобное было.
Исправляется очевидным:
- Учить принципы и теорию;
- Задавать вопросы «А почему здесь именно так?»;
- Читать книги;
- Обсуждать архитектуру.
- Нет структурного мышления. Разработчик или аналитик не может декомпозировать задачи, видеть связи между компонентами, строить логические модели. Он берёт ТЗ и сразу бросается писать код. В итоге не оцениваются риски, не продумываются зависимости. Это из-за отсутствия опыта в проектировании, привычка делать быстро, чтобы быстрее закрыть задачу и отчитаться. Обычно так бывает после крупных компаний. Как-то у меня был опыт работы в корпорации, где нужно было работать с огромным массивом задач, и требовалось быстрее закрывать задачи.
А за ошибки всё равно спрашивают. В итоге, зачем торопиться, если в плохом тайм-менеджменте виноваты не младшие сотрудники, а архитекторы и руководство? Ну да ладно. Без культуры грамотного проектирования на всех уровнях, рождается страх показаться «медлительным». Легко допустить ошибки - дублирование кода, путаницы, отсутствие чёткой структуры. Могут возникать баги из-за непродуманных зависимостей, и задачу порой нельзя передать другому, ведь «только я понимаю эти каракули».
Исправляется рядом правил. Прежде, чем писать код, нужно рисовать схемы - диаграммы классов, последовательностей, состояний (UML или просто блок-схемы), изучать архитектуру. Задачи надо разбивать на подзадачи, использовать методологии и паттерны проектирования вроде SOLID, KISS, YAGNI, DRY.
- Копирование без вникания. Разработчик находит решение на форуме, на другом проекте или получает от нейросети, копирует и вставляет, не вникая, как оно работает. Он не читает код, не задаётся вопросом «Почему это работает?», не изучает побочные эффекты и самое главное - «Можно ли лучше?».
Причины различные - может быть, давление сроков («надо вчера»), лень разбираться или отсутствует код-ревью. В итоге, получаем иллюзию правильного решения, ведь код работает. В перспективе - скрытые баги, уязвимости, утечки памяти, невозможность адаптировать решение под новые условия, и профессиональная деградация.
Никогда не копируйте код, не разобравшись. Переписывайте найденные решения своими словами и тестируйте, задумываясь, «почему оно работает?». С этим поможет справиться код-ревью, крайне эффективная штука.
- Слабые коммуникационные навыки. Здесь важно учитывать, что сферу IT часто выбирают люди в большинстве своём интроверты или холодные и расчётливые, не всегда это активный экстраверты, как этого ожидает бизнес. Разработчик может не уметь объяснить свои решения, вести переговоры, доносить идеи или работать в команде. Он молчит на встречах, пишет непонятные комментарии, не может защитить свою точку зрения. Причины разные, могут быть стереотипы, воспитание или токсичные команды. К примеру, если сеньоры будут издеваться, или уничтожать каждый раз на код-ревью, то появится страх показаться глупым, «вдруг скажу ерунду?». Можно подумать, причиной может быть отсутствие обратной связи от команды, но часто именно негативная обратная связь и прямая критика ломают мотивацию развиваться.
Идеи в итоге не принимаются, карьерный рост останавливается, ведь это «не лидер», появляются конфликты в команде, переоценка задач. Поэтому надо учиться говорить просто и ясно, писать документацию не для себя, а для людей, всегда стараться участвовать во всех встречах, практиковать презентации с демонстрацией экрана и читать книги по этой теме.
- Всё и сразу — неспособность расставлять приоритеты. Разработчик пытается выучить всё, сделать всё, быть везде. Тут его сложно винить, ведь кушать хочется, а требуют постоянно. Он одновременно учит Kubernetes, читает про блокчейн, делает пет-проект на Rust, ходит на митапы, читает 5 книг, отвечает в 10 чатах — и ничего не успевает глубоко.
Такое явление называют FOMO (Fear of Missing Out) — «вдруг все выучат что-то новое, а я останусь без работы?». Результат - поверхностные знания, выгорание, нет глубокой экспертизы и хроническая неудовлетворённость.
Чтобы исправить, нужно ставить цель, составлять дорожную карту, и говорить «нет» технологии, которая отсутствует в дорожной карте.
- Отказ от обучения и обратной связи. Разработчик считает, что «уже всё знает». Он игнорирует ревью, не читает книги, не ходит на митапы, не принимает критику. Он не развивается — и застревает на одном уровне годами. Это как спортсмен, который перестал тренироваться, но удивляется, почему проигрывает.
Почему так? Возможно, эго, страх, и зона комфорта. В итоге следует профессиональная деградация, потеря конкурентоспособности, уход из профессии и разрушение репутации.
Чтобы исправить, нужно…учиться. Вот и всё.
Технологии меняются. Инструменты устаревают. Но способность учиться, думать, общаться, структурировать — остаётся с вами навсегда. Именно она определяет ваш уровень — не язык, не фреймворк, не стаж. Да, поначалу пробиться будет сложно, будут смотреть на «цифры». Но в работе пригодится именно умение.